-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
entities: add pos_navcon
entity
#22
Conversation
To test this, one should copy |
pos_navcon
entity
If we do that we will probably have to avoid circular navcon chains, as the game would never be able to start iterating them, because I guess the best way to start following chains is to start with navcons not having a targetname. |
Or I define a |
Actually it's a better idea. |
I think there are two possible methods to make the game use this data:
Both have their advantages and drawbacks. My first instinct is to go for method 2. The navcon files are simple text files, and provide a unified, tweakable interface. Edit: |
Now with a chain of The idea is that the game would look for all The |
The game, or netradiant, or q3map2, or some other program. We have the choice. |
Of course, but once you implemented 2 you can just copy this implementation in game. 😃️ Actually for both ladders and this we can let the game generate navcon files and then let the game read it again (like we do with navmeshes). We just need to standardize some file names to have multiple navcon files per map, so generating some will not overwrite user-generated navcons. |
It is not that simple. We would have to take the union of the set of navcons in the |
For example we may have:
The entity syntax in the BSP is exactly the same as the |
The sgame will translate/generate at navgen time:
The sgame will load at bot spawn time:
|
I suggest we can also use team names in For example with a navcon doing a long jump down that would kill an human but not an alien, on would just write |
Here is a test map: https://github.com/UnvanquishedAssets/map-chasm_src.dpkdir/raw/illwieckz/navcon-test/maps/chasm.map The chained navcons on the left are a bidir for the The navcon on the right is not bidir and goes from up to down. I wrote |
Currently open questions to ponder:
|
It makes far easier to implement inheritance for things like bidir, classes and radius when there is a clearly identified start entity.
I can just add a radius int field to the start entity description. |
I mean: what will be more intuitive to the casual netradiant user? I have no idea, we should try to ask them. |
Unfortunately we can't name it radius because there is already a radius key with a vec3 in other entities.
There is a portal/camera link, a camera/position link, etc. so it's not that different. |
Maybe something short like |
Also having a clearly identified different name makes easier for the netradiant user to know what entity has the bidir/radius/classes values, especially for someone opening a map he is not author of. |
I added |
7dfb47d
to
493c68e
Compare
I think there are no more open questions, and this is ready to be tested. |
"Someone else" made a prototype at https://github.com/sweet235/navcon-extractor |
@sweet235's navcon extractor worked well for my test-navcons map (to be uploaded s00n™ to https://github.com/UnvanquishedAssets/UnvanquishedTestAssets/tree/master) and I would support being able to optionally generate navcon files from these entities either as part of the navgen process (controversial, I know), or by some other method (q3map2 could do this? or even more controversial: bring back daemonmap?) |
It was written by me and illwieckz.
I made a PR at UnvanquishedAssets/UnvanquishedTestAssets#14
We did not decide that yet. But we do propose that the game shall load more than one navcon file for each class, as described above:
The navcon extractor prototype simply generates what will be |
In the navcon extractor prototype, we implemented |
493c68e
to
060364c
Compare
I split
or do:
I updated https://github.com/sweet235/navcon-extractor accordingly. |
The actual design looks good and fulfills the need, so I guess we can merge it. |
Add
pos_navcon
entity. When linked with atarget
having the same name of anotherpos_navcon
'stargetname
, the game will know it can generate a navcon there.The
bidir
flag can be toggled to make the link bidirectional (from the game point of view, nothing is displayed differently in editor).The
playerclasses
expects a space-separated strings of player classes able to use the navcon, for example:builder level0 level1
.It is expected the game implements the reading of those and generate the related navcons. This is to be done by someone else in the Unvanquished repository.
The current design allows to link multiple navcons in a chain, I suggest that all linked navcons inherit the
playerclasses
from both sides, and chained navcons inherit all the player classes from previouspos_navcon
, but it is recommended to set the playerclass in the first one (the one having notargetname
field).